JavaScript: Extract "organising your code with objects" to new lesson #30778
+368
−177
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Continuing from TheOdinProject#27381 Co-authored-by: Bradley Finney <77649883+takinabradley@users.noreply.github.com>
Now in the new "Organizing Code with Objects" lesson
Goes beyond a sensible scope for this lesson, involving outdated practices. True privacy is covered in later lessons and only an awareness of the idea of privacy and `_` syntax is sufficient.
Lightbulb example demonstrated two simple methods but could raise questions like "why not just assign the property directly?" Tricky to answer with this example without going off on a tangent, especially given the removal of the private/public interface content. The car example's methods should teach the same points but provide a more justified example of using methods over direct/manual interaction.
Double quotes more commonly used across our whole curriculum for JS
Only about constructors now - organisational stuff extracted to separate lesson
Either they'd go out of scope or end up just repeating what the lesson already covers (or already integrated into the lesson in a previous change).
Just introducing the term. Considered putting it in a separate small section before the data structure bit, but felt it would put too much weight on the idea and people would start looking too deeply into namespacing in isolation.
Tough decision. The original assignment, especially without the public/private stuff, felt a bit too contrived without as much practical learning value. Possible readings generally covered much more scope than this lesson (i.e. constructors/classes, inheritance encapsulation etc.) Instead of trying to find an assignment for the sake of an assignment, I felt it would be more sensible to omit an actual assignment since this lesson is mostly basic conceptual "preparation" for the coming lessons and projects.
Clearer separation between "IIFE" and "module pattern" concepts
Actually demonstrate privatisation and need for function rather than just using an object literal directly. Namespacing mention removed as it'll now be brought up in an earlier lesson
Matches lesson style guide
May have been true in earlier times, but especially with classes coming up later, I'd hesitate to use this language right now. I'd rather the context just be presenting an alternative approach than thinking this fully replaces something else because "bad"
mao-sz
force-pushed
the
objects-organisation
branch
from
6a3a209 to
9399e43
Compare
zachmmeyer
approved these changes
Feb 9, 2026
mao-sz
added a commit
to TheOdinProject/theodinproject
that referenced
this pull request
Feb 9, 2026
) New lesson and renamed lesson as part of TheOdinProject/curriculum#30778
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because
Carries on and supersedes #27381.
We start the JavaScript course a little too in the deep end by diving rather quickly into constructors and using objects, but don't really explore a lot of why we would want to use objects in general in the first place, i.e. the more conceptual stuff around code organisation.
Notable changes from original PR
Some examples changed to hopefully demonstrate more justifiable situations. Some felt a little too contrived, with room for questions like "why not just do XYZ instead?"
Reduced scope for the organisation lesson.
After discussion with other team members, we found it difficult to keep the content around public/private in the organisation lesson without it either creeping out of scope with stuff better covered in later lessons, or becoming too contrived that it didn't seem to have as much learning value as intended. Teaching in detail about using
_properties for pseudo-privacy felt like a little too much weight on encapsulation at the wrong time, where it felt more appropriate with things that would actually implement privacy. A brief mention of_properties for awareness, particularly for legacy code, felt more appropriate for this lesson at least.This also tied into the piggy bank assignment which I decided to remove, as without public/private stuff, or things like constructors/factories, felt too contrived to be of significant practical value. Also struggled to find good readings that stayed within this lesson's scope, without going into constructors, classes, inheritance and SOLID etc. Ultimately, I decided on "no assignment", given the more "preparing understanding of concepts" intent behind the new lesson.
Open to counter ideas though.
This PR
Issue
Closes #27375
Additional Information
Only to be merged after TheOdinProject/theodinproject#5228
Pull Request Requirements
location of change: brief description of changeformat, e.g.Intro to HTML and CSS lesson: Fix link textBecausesection summarizes the reason for this PRThis PRsection has a bullet point list describing the changes in this PRIssuesection